SQL Server 2008 provides rich support for various
types of data encryption using symmetric and asymmetric keys and digital
certificates. As an administrator, you probably need to manage at least
the upper level of keys in the hierarchy shown in Figure 1. Each key protects
its child keys, which in turn protect their child keys, down through
the tree. The one exception is when a password is used to protect a
symmetric key or certificate. This is how SQL Server lets users manage
their own keys and take responsibility for keeping the key secret.
Each SQL Server instance has its service master key.
The service master key is the one key that rules them all. It is a
symmetric key created automatically during SQL Server installation and
is encrypted and protected by the Data Protection API (DPAPI), which is
provided by the underlying Windows OS, using the credentials of the SQL
Server service account. Protection of this key is critical because if it
is compromised, an attacker can eventually decipher every key in the
server managed by SQL Server. SQL Server manages the service master key
for you, although you can perform maintenance tasks on it to dump it to a
file, regenerate it, and restore it from a file. However, most of the
time you will not need or want to make any of these changes to the key,
although administrators are advised to back up their service master keys
in the event of key corruption.
The main purpose of the server
master key is to secure system data, such as passwords used in
instance-level settings such as linked servers or connection strings.
The service master key is also used to secure each of the database master keys.
Within each database, the database master key serves as the basis for
creating certificates or asymmetric keys, which subsequently can be
applied to protect data directly or to further extend the encryption
hierarchy (for example, by creating symmetric keys). Creation, storage,
and other certificate and key management tasks can be handled
internally, without resorting to features of the operating system or
third-party products.
Each database can have a single master key. You must create a database master key before using it by using the CREATE MASTER KEY Transact-SQL statement with a user-supplied password:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'R@nD0m!T3%t'
SQL Server encrypts the
database master key using a triple DES key derived from the password as
well as the service master key. The first copy is stored in the
database, and the second is stored in the master database. Having the
database master key protected by the server master key makes it possible
for SQL Server to decrypt the database master key automatically when
required. The application or user does not need to open the master key
explicitly using the password. This is a major benefit of having the
keys protected in the hierarchy.
Note
Detaching a database with an
existing master key and moving it to another server can be an issue. The
problem is that the new server’s database master key is different from
that of the old server. As a result, the server cannot automatically
decrypt the database master key. This situation can be circumvented by
opening the database master key with the password with which it is
encrypted and using the ALTER MASTER KEY statement to encrypt it with the new database master key.
When the database master key
exists, developers can use it to create any of three types of keys,
depending on the type of encryption required:
Asymmetric keys
Symmetric keys
Certificates
Tip
Microsoft recommends
against using certificates or asymmetric keys for encrypting data
directly. Asymmetric key encryption is many times slower, and the amount
of data that you can protect using this mechanism is limited, depending
on the key modulus. It is recommended that you protect certificates and
asymmetric keys using a password instead of by the database master key.
Extensible Key Management
Another new feature in SQL
Server 2008 that provides greater key security is Extensible Key
Management. EKM enables you to manage your encryption keys via an
external provider. This allows for flexibility and choice in encryption
providers as well as common key management across your enterprise.
With the growing demand for
regulatory compliance and concern for data privacy, organizations are
taking advantage of encryption as a way to provide a “defense in depth”
solution. As organizations increasingly use encryption and keys to
secure their data, key management becomes more complex. Some high
security databases use thousands of keys, and you must employ a system
to store, retire, and regenerate these keys. This approach is often
impractical using only database encryption management tools. As a
solution, various hardware vendors provide products to store encryption
keys on hardware or software modules. These products also provide a more
secure key management solution because the encryption keys do not
reside with encryption data. They also move the key management workload
from SQL Server to a dedicated key management system.
Extensible key management
in SQL Server 2008 also supports the use of Hardware Security Module,
which enables the encryption keys used to protect your data to be stored
in an off-box device such as a smartcard, USB device, or EKM/HSM
module, providing a physical separation of keys from data. SQL Server
2008 Extensible Key Management enables third-party EKM/HSM vendors to
register their modules in SQL Server. When registered, SQL Server users
can use the encryption keys stored on EKM modules. This enables SQL
Server to access the advanced encryption features these modules support
such as bulk encryption and decryption, and key management functions
such as key aging and key rotation.
SQL Server 2008
Extensible Key Management also provides data protection from database
administrators. Data can be encrypted by using encryption keys that only
the database user has access to on the external EKM/HSM module.
To summarize, SQL Server 2008 Extensible Key Management provides the following benefits:
An additional authorization check that enables separation of duties between database administration and key management
Improved performance through hardware-based encryption/decryption rather than software-based encryption/decryption
External encryption key generation
Physical separation of data and keys
Encryption key retrieval
External encryption key retention and encryption key rotation
Easier encryption key recovery
Manageable encryption key distribution
Secure encryption key disposal
When possible, it is
highly recommended that you use EKM with both database- and column-level
encryption for more comprehensive key management and hardware-based
cryptography.
